[workspace] Remove drake_vendor prefix from our include paths #19936
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jwnimmer-tri
added
priority: low
release notes: fix
|
@drake-jenkins-bot linux-focal-unprovisioned-gcc-wheel-experimental-release please |
|
+@rpoyner-tri for feature review, please. |
rpoyner-tri
reviewed
Aug 4, 2023
There was a problem hiding this comment.
Reviewed 57 of 57 files at r1, all commit messages.
Reviewable status: 1 unresolved discussion, needs at least two assigned reviewers
-- commits line 29 at r1:
typo
Suggestion:
users
The purpose of the non-traditional include path within Drake (e.g.,
including <drake_vendor/tinyxml2.h> instead of just <tinyxml2.h>)
was to avoid the hazard of accidentally picking up the OS copy of
the header (e.g., `/usr/include/tinyxml2.h`).
When all of the BUILD files are correct, there is no hazard -- Bazel
will always place the Drake-internal copy earlier on include path and
that will always win out over the OS copy. Instead, the hazard happens
during local development, while build system maintainers are iterating
adding or updating externals. This had some moderate benefit as we've
been iterating to build more and more externals from source. The
ongoing benefit is more limited.
It also has some drawbacks. Downstream users of Drake who use our
build system without modifications are fine, but more advanced users
who want to substitute these dependencies with their own builds of the
libraries suffer: they either need to provide their copy of the
library with a weird `drake_vendor` include path, or patch Drake to
switch the `#include` statements in the source code back to normal.
There is an ongoing cost here for them, to keep up-to-date with
regular updates and Drake churns.
On balance, the path switcheroo does not seem worth it anymore. Here,
we undo all of the `drake_vendor` additions to the include paths. The
ODR-safe addition of `namespace drake_vendor { ... }` in our own
source builds of externals remains unchanged. The users with their own
builds can keep that intact or skip it, at their discretion.
jwnimmer-tri
force-pushed
the
rm-drake_vendor-include-path
branch
from
afcb0a1 to
7504f72
Compare
|
Hmm, are you OK with "single reviewer" here @rpoyner-tri? As it happens, this will be on the critical path for the VTK upgrade. |
19 tasks
rpoyner-tri
added
the
status: single reviewer ok
rpoyner-tri
reviewed
Aug 6, 2023
There was a problem hiding this comment.
Reviewed all commit messages.
Reviewable status:complete! all discussions resolved, LGTM from assignee rpoyner-tri(platform)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The purpose of the non-traditional include path within Drake (e.g., including
<drake_vendor/tinyxml2.h>instead of just<tinyxml2.h>) was to avoid the hazard of accidentally picking up the OS copy of the header (e.g.,/usr/include/tinyxml2.h).When all of the BUILD files are correct, there is no hazard -- Bazel will always place the Drake-internal copy earlier on include path and that will always win out over the OS copy. Instead, the hazard happens during local development, while build system maintainers are iterating adding or updating externals. This had some moderate benefit as we've been iterating to build more and more externals from source. The ongoing benefit is more limited.
It also has some drawbacks. Downstream users of Drake who use our build system without modifications are fine, but more advanced users who want to substitute these dependencies with their own builds of the libraries suffer: they either need to provide their copy of the library with a weird
drake_vendorinclude path, or patch Drake to switch the#includestatements in the source code back to normal. There is an ongoing cost here for them, to keep up-to-date with regular updates and Drake churns.On balance, the path switcheroo does not seem worth it anymore. Here, we undo all of the
drake_vendoradditions to the include paths. The ODR-safe addition ofnamespace drake_vendor { ... }in our own source builds of externals remains unchanged. The users users with their own builds can keep that intact or skip it, at their discretion.Related to #17231.
This change is